[CSTACKEX-339] ASUP Upstream review comments - #117

Description

1- This allocates an intermediate list and then traverses it three more times. Since this runs once per pool per interval, on very large pools this adds avoidable CPU/GC overhead. Consider computing rootDiskCount, dataDiskCount, and totalLogicalSizeBytes in a single pass over volumes (filtering by CS_VOLUME_STATES inline) to reduce allocations and repeated streaming.
2- This treats a missing/unknown is_all_flash_optimized (null) as false, which classifies the node as fas and can incorrectly set cluster platformType when ONTAP doesn’t return these fields (permissions/older versions/partial responses). Consider returning null (unknown) when the required flags are absent and only adding non-null classifications to the rollup set so ASUP doesn’t misreport hardware type.
3- The DAO method is documented as “non-destroyed” volumes, but the SQL currently includes volumes in transitional/pre-provisioning states (e.g., Allocated) because it only excludes Destroy/Expunged. That can incorrectly flip multiPrimaryStoragePoolVm=true for VMs whose data disk hasn’t actually been created/moved yet. Tighten the state predicates to align with the intended “physically exists” semantics (e.g., include only the same stable states you count elsewhere, or explicitly exclude Allocated/upload-related states).
4- lock.unlock() is executed even when lock.lock(...) returns false (early return), which can attempt to unlock a lock this thread never acquired. Additionally, GlobalLock.getInternLock(...) typically requires releasing the reference (e.g., releaseRef()) to avoid leaking the interned lock object. Track a boolean locked and only unlock() when true, and ensure the lock reference is released in finally (even when not acquired).

fixed the above issues

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

How did you try to break this feature and the system with this change?